This is probably the most common thing that I see when evaluating propositions.

Regardless of the passion of the founders, sometimes the idea they are pursuing is not a full-blown product or service in its own right, but rather, a feature or subset of something else that already exists.

The danger here is that incumbents see the new idea and then just go on to add it as a feature to their existing product or service, squashing you in the process.

In recent times, this kind of thing has become standard operating procedure with incumbent social media networks as a way to kill competition from upstart startups.

This is a simple test to see if the proposition has any potential at all to capture users who really care about the idea.

If the answer is “no”, then there is a risk that they may never be able to get anyone to care about it.

Far too often, founders confuse themselves for their users.

Rather than honestly exposing the product or service to real users with a rigorous attention to how it fares in real-world conditions, they mistake their own preferences and biases for genuine user feedback.

No matter what the founders might think, there is no substitute for putting the product or service in front of real users, seeing what they do with it, and then incorporating those learnings into subsequent iterations.

This problem is particularly apparent for me in my work because we sometimes come across “passion projects” driven from senior executives in the client.

Unfortunately, they can sometimes be quite removed from what their real users are doing and thinking and so end up anchoring on their own ideas rather than constantly testing and learning with their actual users.

This is probably the saddest of these heuristics because you can have a situation where a team has spent an enormous amount of time and effort building something, but what they have built is a solution to a problem no-one actually has.

This is also known as the “build it and they will come” fallacy.

Engineers are particularly susceptible to this mistake (I know because I have made it myself, and more than once!) which is why it’s always good for a team to have a mix of engineering, design, product, and business skills working on the solution to balance out this bias.

If they don’t, the team may end up veering towards “solutioneering” rather than genuine innovation.

The idea here is that if I am evaluating a proposition, then I’m prepared to concede that the team can still succeed even if they have to create one miracle.

In fact, if a team is going for something really ambitious and they don’t require at least one miracle to pay off, then perhaps they’re not being ambitious enough!

However, if I look at a proposition and I see that the team needs miracle after miracle to come true for them to succeed, then I start to wonder if they may be too ambitious.

If the miracles start to pile up across design, business, engineering, and go-to-market, then I really start to get worried.

On their own, each heuristic can act as a useful test when evaluating a proposition. Taken together, they can work powerfully to help separate ideas worth pursuing from those that might be better off getting less attention. However, keep in mind that these are just heuristics and the best validation for any idea is to put real software in front of real users and ask them what they think.

This piece was originally published by Matthew on Medium.